Organizations rely on computing systems and applications to perform different business processes. For example, inventory control systems may be used to manage and track product distribution and task management systems may track progress to a goal. Although organizations often obtain different systems from different manufacturers, they nonetheless expect the different systems to interact with each other.
This is especially true when organizations develop new applications or functionality in existing applications to support new business processes. Aside from expecting interactivity between systems, organizations also seek to minimize costs when developing these new applications or functionalities. One way of minimizing development costs is to use business process modeling software to enable business analysts and those familiar with the organization's business processes to model those processes. However, development costs are not fully minimized because an experienced computer programmer may still be needed to convert the modeled processes into application code.
Business Process Modeling Notation (BPMN) may be used to graphically represent and model business processes. BPMN uses standardized symbols and flowcharts to visually describe processes intuitively to business users while also incorporating complex functions and semantics for technical users. This functionality makes BPMN useful to both business and technical users.
FIG. 1 shows an exemplary business process model 100 based on the BPMN specification. The model includes a pool 110 that may be subdivided into one or more lanes 120. A pool 110 may represent an entity involved in a process. An entity may include a technical system, business partner, corporate subsidiary, branch, or other division of systems or organizations. If multiple entities are involved in completing a process, then multiple pools may be included in the model. Each pool 110 may contain one or more lanes 120. A lane 120 may be used to organize and separate different functions or roles within an entity. Lanes may contain flow objects, connecting objects, and artifacts. Flow objects may include events 121, 123, 125, activities, or tasks 124. Connecting objects may include sequence flows 122 and message flows 131. Artifacts may include data objects 132.
An event 121, 123, 125 represents a synchronization between a business process and an external environment, which may occur by sending or receiving an event to a component of the external environment. An activity or task 124 represent something is performed. A start event 121 triggers the start of a process and is also known as a Catch Event because it may receive or “catch” an incoming message to begin the process. Intermediate events 123 represent actions, such as catch or throw events, that occur between the start and end of a process. End events 125 represent a concluding result of completing the process. End events 125 may also be known as Throw Events because they may send or “throw” the concluding result to another entity, process, or system.
Activities and tasks 124 may represent work that is to be performed by an entity or process. Sequence flows 122 may represent a chronological order in that steps of a process are executed. Message flows 131 may show the types of messages that may be exchanged between different business processes, that may, in some instances, be exchanged between different organizations, systems, or entities. Finally, data objects 132 may identify a local state of a business process.
While business process models, including BPMN-compliant models, may be used by business users to intuitively model business processes, application code may not be directly generated from these business process models. Furthermore, organizations with multiple systems from different vendors that expect interactivity between the systems may not be able to simply convert business process models to application code. Thus, the practicality of business process models has been limited to intuitive visualizations of business processes.
There is a need for converting business process models to programming and component models better suited for application delivery that conform with the principles of a technologically agnostic service-oriented architecture to support connectivity between different systems.